Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000146_owner-urn-ietf _Wed Nov 13 14:10:33 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10001 for urn-ietf-out; Wed, 13 Nov 1996 14:10:33 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09995 for <[e-mail]>; Wed, 13 Nov 1996 14:10:27 -0500
Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA13304  (mail destined for [e-mail]); Wed, 13 Nov 96 14:10:18 -0500
Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK)
          id OAA15428; Wed, 13 Nov 1996 14:05:06 -0500 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh version 1.6.7 5/3/96
X-Uri: http://www.cs.utk.edu/~moore/
From: Keith Moore <[e-mail]>
To: Martin J Duerst <[e-mail]>
Cc: [e-mail] (Keith Moore), [e-mail],
        [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail]
Subject: Re: [URN] Please avoid "URNs are"
In-Reply-To: Your message of "Wed, 13 Nov 1996 19:41:54 +0100."
             <"josef.ifi..077:13.10.96.18.41.56"@ifi.unizh.ch>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 13 Nov 1996 14:05:06 -0500
Sender: [e-mail]
Precedence: bulk
Reply-To: Keith Moore <[e-mail]>
Errors-To: [e-mail]

> >> PLEASE avoid saying "URNs are XXX". Please use wording such
> >> as "URNs are noted on paper as XXX", "URNs are represented
> >> on computers in the following forms...", or "URNs represent
> >> characters from the following set..." or whatever.
> >
> >I'm not sure how much difference it makes.  RFC 1737 requires
> >the following:
> >
> >   o Single encoding: The encoding for presentation for people in clear
> >     text, electronic mail and the like is the same as the encoding in
> >     other transmissions.
>
> This requirement makes sense in the sense that the number of different
> representations and encoding should be as low as possible.

I hope that "as low as possible" is equivalent to "one".

> But it does not say anything about how URNs are noted on paper.

No it doesn't.  But it seems reasonable to expect that people will
transcribe URNs from their screens to paper, and from that paper to
keyboard.  The result of doing so had better produce the same URN.

Also, we can't assume that the transcription of a URN from paper to
keyboard will be through an intelligent tool that understands how to
translate URNs from display format to some other format.  A URN could
certainly be sent via email, transcribed to paper, and typed back into
plain text email by someone else.

For grandfathering other URN schemes, non-universal characters will
need to be converted into sequences of universal characters.  That way
there can be a well-defined conversion from {j.random.naming.scheme}
to URN, but only one format for the URN once it's converted.  It's
fine if smart software recognizes certain types of URNs and undoes the
conversion, so long as the unconverted form is displayed as an
identifier from {j.random.naming.scheme} and NOT as a URN.

As for URNs encoded in EBCDIC: we should probably define URNs as
sequences of characters, which can be represented in any character
encoding scheme, so long as:

+ that encoding scheme is clearly labeled (e.g. MIME charset) whenever
multiple encodings can appear in the same context, and

+ there is a unique encoding in that scheme for each character that
can appear in a URN.

So URN character sequences could be encoded in ASCII or EBCDIC or
UCS-32 or whatever and still be URNs.

Keith